@francoisferrand I tried the curl command provided in the doc we gave to the client :
curl -X PUT "http://localhost:8000/testb/?quota=true" --user "accessKey1:verySecretKey1" --aws-sigv4 "aws:amz:us-east-1:s3" -d '{"quota" : 32}'

In that case, curl will not set the content-type header. So I think it's tricky to modify the logic around the body parsing by using content type, because clients can't be expected to set that header so no matter what we will have to use a fallback which is basically the code that we already have with the try/catch

maybe we should check the contentType if set (and default to JSON if not) ?

switch(contentType) {
case 'xml':
   return parseString(requestBody, { explicitArray: false }, (xmlError, xmlData) => { [...] };

case 'json':
default:
   const jsonData = JSON.parse(requestBody);
   return next(null, jsonData);
}

could be a followup ticket, or just this one as it is probably simple:

• probably a good time to make this change: 9.3 already has "risky" changes, and we have time before we ship it
• should be fine if we keep JSON as fallback (according to the docs which were shared)
• esp. quota API is not widely used at the moment
• but we need to test it explicitly to avoid any surprise

yes let's make that change and add it in 9.3

wanna do this now, because this change is for the cloudserver quota client feature, and I need an image with this new code to run in the test pipeline. Otherwise can't merge the new client

should it not be something like this:
(may be the same, but closer to how AWS documents its own api...)

the api is written with quota=true in the client doc, the existing tests are also using quota=true.
Upon testing it seems that all of these will work :
{bucketName}/quota=true
{bucketName}/quota=false
{bucketName}/quota=
{bucketName}/quota

But considering the existing documentation and code, I think we can keep using quota=true